Subject: RE: Update of RFC 2838, tv: URI

From: "Deventer, M.O. \(Oskar\) van" <[email-masked]>
Date: Tue, 22 Aug 2006 17:08:07 +0200

Da, all,

(Dan, thank you for forwarding your response. I missed it on the mailing
list)

> I would be happy to work on a revision of RFC 2838 if one is desired
Thank you.

> broadcasters have not rushed to establish identifiers based on this
scheme
This is the good thing about the RFC 2838 tv: URI. It allows me to
create internet-based services that point to TV channels without being
dependent on the collaboration of broadcasters. Many use cases (see
previous posts in this thread) would not need such collaboration, but
only an unambiguous identification of TV channels.

> I'm not sure I agree that this approach runs into any particular
problems in Europe.
Following the RFC 2838 scheme, both tv:bbc1.bbc.co.uk and
tv:one.bbc.co.uk would be proper tv: URI to identify the BBC1 TV
channel. If my application use the one and your application uses the
other, we have an interoperability problem. The Dutch situation is even
worse with at least four synonyms for NED1 and a plethora of domain
names that could be applicable.

> the biggest problem is how to register identifiers under this scheme.
The whole idea is that no registration is needed at all, if the
deduction/derivation of the tv: URI from the website name is
sufficiently unambiguous.

Best regards,

Oskar

---------- Forwarded message ----------
From: Dan Zigmond <[email-masked]>
Date: Aug 21, 2006 10:01 AM
Subject: Re: Update of RFC 2838, tv: URI
To: Keith Moore < [email-masked] <mailto:[email-masked]> >, Lisa
Dusseault <[email-masked]>, Tim Bray <[email-masked]>,
[email-masked], Eliot Lear <[email-masked]>, "Keesmaat, N.W.
(Iko)" <[email-masked]>

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
<http://www.google.com/url?sa=D&q=http%3A%2F%2Fnbc.com> , tv: cnn.com
<http://www.google.com/url?sa=D&q=http%3A%2F%2Fcnn.com> , and
tv:one.bbc.co.uk
<http://www.google.com/url?sa=D&q=http%3A%2F%2Fone.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
<http://www.google.com/url?sa=D&q=http%3A%2F%2Fbbc1.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
<http://www.google.com/url?sa=D&q=http%3A%2F%2Fbb1.bbc.co.uk%2Fnews>  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 < [email-masked] <mailto:[email-masked]> >
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
<http://www.google.com/url?sa=D&q=http%3A%2F%2Fmicroformats.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

-- 

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

-- 

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

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Aug 2006 11:48:45 -0400

> only an unambiguous identification of TV channels.

I'm not sure it's entirely a good thing to have a scheme that encourages 
creation of identifiers for broadcasters without their participation. 
If nothing else, it seems like it would be difficult to keep the 
URI-to-broadcaster mappings up to date (say when they change their 
domain names, or call letters - maybe because a station is sold to a new 
owner or wishes to change its target market) without the cooperation of 
the broadcasters.

I like the idea of using domain names in tv: URIs, but broadcasters 
should be allowed/encouraged to use DNS to associate information about 
their channels with the TV URI.  I dislike the idea of using web page 
addresses as tv: URIs for reasons mentioned earlier, but also because 
web page addresses (including both the domain and a path) change more 
frequently than domain names, as web sites get reorganized.

Keith

---

From: "Dan Zigmond" <[email-masked]>
Date: Tue, 22 Aug 2006 09:40:11 -0700

I think I agree with Keith here. But first, I would like to emphasize that
there is no essentially "European" issue with RFC 2838. Rather, the issue is
that one cannot unambiguously deduce the correct tv: URL for a given
broadcaster without additional information.

But this is a very loose sort of ambiguity, and it exists everywhere on the
Internet. You cannot deduce my email address unless I tell you; based on my
name and employer, it could easily be [email-masked], for example, or
[email-masked], or any of a very large number of plausible things.
The basic standards simply allow me to pick one, but do not mandate which
one I choose or how I tell you my choice. Similarly, you can't deduce an
HTTP URI from a  domain name either. Google is free to support, say,
http://www.google.com, http://google.com, or http://foo.google.com (or any
combination). Unless someone tells your which one is in use, you can't
accurately guess. The situation with tv: is the same.

Second, I don't see how supporting path components like
tv:bbc.co.uk/bbconewould solve the basic problem. You would still have
many potential
ambiguities. As Oskar notes, there can be multiple web sites for a given
broadcast. But how do you know that the various sites refer to the same
underlying TV signal? You could use HTTP to detect redirects (assuming all
devices supporting tv: also support HTTP, which is doubtful), but this can't
be guaranteed to be a reliable indicator. Perhaps the two different sites
don't redirect, or use slightly different content for some reason. Perhaps
for a week, both http://bbc.co.uk/bbcone and hhtp://bbc.co.uk/bbctwo
redirect to the same "Under Construction" page. Should the corresponding tv:
URIs be treated as equivalent during that week? And as Keith notes, web
sites changes fairly frequently, while new TV broadcasts are introduced very
rarely these days.

In some cases, the opposite problem will exist, too. In the US, for example,
both HBO East and HBO West share the same web pages, because they are the
"same" channel, but with the West version delayed three hours. Yet my TV
receives both, and I need to be clear about which one to tune to if I want
to watch a given program since at any given moment they are almost
guaranteed to show distinct content.

In summary, I agree that a problem exists with RFC 2838: there is no
universal way for everyone to agree on which tv: URIs refer to which TV
broadcasts. But I don't think the proposed change solves this problem. The
only solution I can think of is a central registry to which broadcasters
would be encouraged to submit unique tv: identifiers for their broadcasts.

     Dan

-- 

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